Remove deterministic picking from query cycle handling#152229
Remove deterministic picking from query cycle handling#152229Zoxc wants to merge 1 commit intorust-lang:mainfrom
Conversation
|
cc @nnethercote |
|
☔ The latest upstream changes (presumably #152484) made this pull request unmergeable. Please resolve the merge conflicts. |
| let entry_point = entry_points | ||
| .iter() | ||
| .find(|entry_point| entry_point.waiter.is_some()) | ||
| .unwrap_or(entry_points.first().unwrap()); |
There was a problem hiding this comment.
| .unwrap_or(entry_points.first().unwrap()); | |
| .unwrap_or(entry_points[0]); |
| if query_in_cycle.parent(query_map).is_none() { | ||
| // This query is connected to the root (it has no query parent) | ||
| Some((span, query, None)) | ||
|
|
There was a problem hiding this comment.
Nit: stray empty line.
|
If the existing approach is indeed non-deterministic, then this looks like a good simplification. |
rustc_query_impl: Use `ControlFlow` in `visit_waiters` instead of nested options Noticed when reviewing rust-lang#152229.
rustc_query_impl: Use `ControlFlow` in `visit_waiters` instead of nested options Noticed when reviewing rust-lang/rust#152229.
|
Good simplification. The r=me after rebasing and with petrochenkov's comments addressed. |
Is it worth adding a comment somewhere that mentions this? Seems like useful information. |
This removes the deterministic picking of queries from the query cycle handling. The sets we pick from are themselves non-deterministic, making this ineffective. There may be additional entry points to the cycle which we won't discover until after we resume from the cycle handler and run more code.